feat(mobile,trpc,auth,db): grace-period account deletion with reactivation - #6395

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect the declared Stripe SDK version and existing pagination patterns.
fd -a '^package\.json$' . -E node_modules -0 |
  xargs -0 rg -n -C2 '"stripe"|`@superset/auth`'

rg -n -C3 'subscriptions\.list|autoPagingEach|starting_after|has_more' packages apps

Repository: superset-sh/superset

Length of output: 5304

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '--- user deletion mutation ---'
sed -n '45,105p' packages/trpc/src/router/user/user.ts

printf '%s\n' '--- existing organization deletion hook ---'
sed -n '535,570p' packages/auth/src/server.ts

printf '%s\n' '--- Stripe package metadata ---'
rg -n -C3 '"stripe": "20\.4\.1"|stripe@20\.4\.1|subscriptions\.list' bun.lock* package.json packages apps

Repository: superset-sh/superset

Length of output: 6179

🌐 Web query:

Stripe Node.js SDK 20.4.1 subscriptions.list autoPagingEach pagination has_more documentation

💡 Result:

In the Stripe Node.js SDK, the autoPagingEach method automates the process of traversing all pages in a list request, abstracting away the need for you to manually manage the has_more flag or pagination cursors (starting_after/ending_before) [1][2][3]. When you call.autoPagingEach on a list method (such as stripe.subscriptions.list), the SDK handles the underlying API logic for you [2][4]: 1. Internal Pagination: The SDK performs an initial request and inspects the has_more property in the response [5][6][7]. 2. Automatic Fetching: If has_more is true, the SDK automatically executes subsequent API calls to fetch the next page, using the appropriate cursor to maintain continuity [5][6][7]. 3. Iteration: It yields each object to your provided callback function [2][8]. 4. Termination: The iteration stops automatically when the API returns a response where has_more is false [6][7]. You do not need to check has_more yourself when using autoPagingEach; the SDK manages this state internally to ensure you retrieve all objects matching your initial query parameters [1][2][7]. Usage Example: await stripe.subscriptions.list({ limit: 100 }).autoPagingEach(async (subscription) => { // The SDK handles pagination; this function runs for every subscription. console.log(subscription.id); // Return false to break the iteration early if needed. if (shouldStop) { return false; } }); If you are using a modern Node.js environment that supports async iterators, you can also use a for-await-of loop, which provides the same auto-pagination functionality: for await (const subscription of stripe.subscriptions.list({ limit: 100 })) { console.log(subscription.id); } The has_more property is a standard part of the Stripe API list response object, which the SDK's auto-pagination helper uses to determine if another request is necessary [5][6][7]. When manually handling pagination, you would typically check has_more to decide whether to make another request using the ID of the last object as the starting_after cursor [7].

Citations:

• 1: https://docs.stripe.com/api/pagination/auto?lang=node
• 2: https://github.com/stripe/stripe-node?tab=readme-ov-file
• 3: https://docs.stripe.com/api/pagination
• 4: https://docs.stripe.com/api/pagination/auto
• 5: https://github.com/stripe/stripe-node/blob/625f1988/src/autoPagination.ts
• 6: https://github.com/stripe/stripe-node/blob/47cdb5eb/src/autoPagination.ts
• 7: https://docs.stripe.com/pagination
• 8: https://github.com/stripe/stripe-node/blob/master/README.md

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- server.ts relevant sections ---'
sed -n '1,230p' packages/auth/src/server.ts

printf '%s\n' '--- auth/session/deletion references ---'
rg -n -S \
  'cookieCache|getSessionFromCtx|PENDING_DELETION_ALLOWED_PATH_PREFIXES|deletedAt|pending deletion|delete.*session|session.*delete' \
  packages/auth

Repository: superset-sh/superset

Length of output: 8212

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- package versions ---'
rg -n -S '"better-auth"|better-auth@' package.json bun.lockb bun.lock packages --glob 'package.json' --glob 'bun.lock*' 2>/dev/null || true

printf '%s\n' '--- deletion and session-related implementation ---'
sed -n '820,930p' packages/auth/src/server.ts
rg -n -S \
  'delete.*account|account.*delete|deleted_at|deletedAt|deleteMany|revoke|session' \
  packages apps --glob '*.{ts,tsx,js,jsx}' --glob '!**/node_modules/**' | head -300

printf '%s\n' '--- auth schema ---'
fd -i 'auth' packages/db
rg -n -S 'deletedAt|deleted_at|sessions|users' packages/db --glob '*.{ts,tsx}'

Repository: superset-sh/superset

Length of output: 49109

🌐 Web query:

Better Auth cookieCache maxAge revoked sessions remain active documentation getSessionFromCtx disable cache

💡 Result:

In Better Auth, the cookieCache feature improves performance by storing session data in a signed, short-lived cookie to avoid frequent database lookups [1][2]. Because this data is stored in the client's browser, revoked sessions may remain active on other devices until the cache duration (maxAge) expires [1][3]. The server cannot directly invalidate or delete cookies stored on other client devices [2][3]. To manage or mitigate this behavior, you can use the following approaches: Immediate Revocation Strategies If immediate session revocation is required, you can: 1. Disable cookieCache entirely in your configuration [1][2]. 2. Set a significantly shorter maxAge (e.g., 60 seconds) to balance performance and security [1][2]. 3. Use disableCookieCache: true for sensitive operations or specific API calls to force a fresh database lookup [1][3]. Handling Cookie Cache with getSessionFromCtx When calling getSessionFromCtx, you can force the server to bypass the cache and validate the session against the database by passing the disableCookieCache: true option [4][3]. Important Implementation Note: When using disableCookieCache: true, ensure that your environment correctly handles the updated session headers. In some server-side contexts (like certain middleware or specific internal API patterns), the set-cookie header generated by the refresh may be discarded if the call is not configured to return and forward headers to the final client response [5][6]. To ensure the client-side cookie is actually updated, you may need to ensure the calling context handles the headers explicitly, such as by using returnHeaders: true when invoking session-related methods [5][6].

Citations:

• 1: https://better-auth.com/docs/concepts/session-management
• 2: https://raw.githubusercontent.com/better-auth/better-auth/refs/heads/main/docs/content/docs/concepts/session-management.mdx
• 3: https://github.com/better-auth/better-auth/blob/main/docs/content/docs/concepts/session-management.mdx
• 4: https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/api/routes/session.ts
• 5: getSessionFromCtx discards session_data cookie refresh — JWE session expires after maxAge with no renewal better-auth/better-auth#8763
• 6: Cookie cache not updated from auth.api.getSession better-auth/better-auth#4231

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- all repository references to pending deletion ---'
rg -n -S 'deletedAt|deleted_at|pending deletion|pending-deletion|delete account|account deletion|deleteAccount' . \
  --glob '!bun.lock' --glob '!**/.git/**' --glob '!**/node_modules/**' | head -300

printf '%s\n' '--- auth schema and relevant migrations ---'
sed -n '1,75p' packages/db/src/schema/auth.ts
rg -n -S 'deleted_at|deletedAt' packages/db/drizzle packages/auth

printf '%s\n' '--- Better Auth 1.6.22 session implementation references ---'
tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
curl -fsSL https://raw.githubusercontent.com/better-auth/better-auth/v1.6.22/packages/better-auth/src/api/routes/session.ts \
  -o "$tmpdir/session.ts"
curl -fsSL https://raw.githubusercontent.com/better-auth/better-auth/v1.6.22/packages/better-auth/src/api/index.ts \
  -o "$tmpdir/api-index.ts" || true
rg -n -C 8 -S 'disableCookieCache|cookieCache|getSessionFromCtx|session' "$tmpdir"

Repository: superset-sh/superset

Length of output: 50377

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- account deletion flow ---'
sed -n '50,150p' packages/trpc/src/router/user/user.ts
sed -n '70,135p' packages/trpc/src/trpc.ts

printf '%s\n' '--- Better Auth 1.6.22 cookie-cache decision path ---'
tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
curl -fsSL https://raw.githubusercontent.com/better-auth/better-auth/v1.6.22/packages/better-auth/src/api/routes/session.ts \
  -o "$tmpdir/session.ts"
curl -fsSL https://raw.githubusercontent.com/better-auth/better-auth/v1.6.22/packages/better-auth/src/api/context.ts \
  -o "$tmpdir/context.ts" || true
rg -n -C 12 -S \
  'sessionDataPayload|cookieCache|disableCookieCache|internalAdapter\.getSession|getSessionFromCtx|sessionDataCookie' \
  "$tmpdir/session.ts" "$tmpdir/context.ts" | head -240

printf '%s\n' '--- getSessionFromCtx declaration and implementation ---'
curl -fsSL https://raw.githubusercontent.com/better-auth/better-auth/v1.6.22/packages/better-auth/src/api/index.ts \
  -o "$tmpdir/index.ts"
rg -n -C 12 -S 'getSessionFromCtx|disableCookieCache' "$tmpdir/index.ts"

Repository: superset-sh/superset

Length of output: 20708

🏁 Script executed:

#!/bin/bash
set -eu

tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
curl -fsSL https://raw.githubusercontent.com/better-auth/better-auth/v1.6.22/packages/better-auth/src/api/routes/session.ts \
  -o "$tmpdir/session.ts"

printf '%s\n' '--- getSessionFromCtx exact implementation ---'
sed -n '527,590p' "$tmpdir/session.ts"

printf '%s\n' '--- cookie-cache return and database fallback ---'
sed -n '213,360p' "$tmpdir/session.ts"

printf '%s\n' '--- auth middleware dispatch/session context setup ---'
for path in \
  packages/better-auth/src/api/dispatch.ts \
  packages/better-auth/src/api/middlewares/index.ts \
  packages/better-auth/src/api/middlewares/session.ts; do
  url="https://raw.githubusercontent.com/better-auth/better-auth/v1.6.22/$path"
  if curl -fsSL "$url" -o "$tmpdir/$(basename "$path")"; then
    printf '%s\n' "--- $path ---"
    rg -n -C 8 -S 'context\.session|session.*context|getSession' "$tmpdir/$(basename "$path")" | head -160
  fi
done

Repository: superset-sh/superset

Length of output: 9461

🏁 Script executed:

#!/bin/bash
set -eu

tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
curl -fsSL https://raw.githubusercontent.com/better-auth/better-auth/v1.6.22/packages/better-auth/src/api/routes/session.ts \
  -o "$tmpdir/session.ts"

printf '%s\n' '--- getSessionFromCtx continuation ---'
sed -n '540,610p' "$tmpdir/session.ts"

printf '%s\n' '--- database fallback after cookie-cache branch ---'
sed -n '350,525p' "$tmpdir/session.ts"

printf '%s\n' '--- static behavioral verifier ---'
python3 - <<'PY'
from pathlib import Path
import re

server = Path("packages/auth/src/server.ts").read_text()
deletion = Path("packages/trpc/src/router/user/user.ts").read_text()
trpc = Path("packages/trpc/src/trpc.ts").read_text()

assert re.search(r"cookieCache:\s*\{\s*enabled:\s*true,\s*maxAge:\s*60 \* 5", server, re.S)
assert "const session = await getSessionFromCtx(ctx);" in server
assert ".set({ deletedAt: new Date() })" in deletion
assert "await db.delete(sessions).where(eq(sessions.userId, userId));" in deletion
assert "ctx.session.user.deletedAt" in trpc

# Model the Better Auth 1.6.22 branch observed in session.ts:
# a valid cookie payload is returned before the database lookup unless
# disableCookieCache is true.
def session_source_uses_cookie_cache(cookie_valid: bool, cache_enabled: bool,
                                     disable_cookie_cache: bool) -> bool:
    return cookie_valid and cache_enabled and not disable_cookie_cache

assert session_source_uses_cookie_cache(True, True, False)
assert not session_source_uses_cookie_cache(True, True, True)
print("stale cookie cache can bypass the hook's current session lookup; strict lookup requires disableCookieCache.")
PY

Repository: superset-sh/superset

Length of output: 8089

🏁 Script executed:

#!/bin/bash
set -eu

tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
curl -fsSL https://raw.githubusercontent.com/better-auth/better-auth/v1.6.22/packages/better-auth/src/api/routes/session.ts \
  -o "$tmpdir/session.ts"

printf '%s\n' '--- Better Auth authoritative-session helper ---'
sed -n '590,690p' "$tmpdir/session.ts"

printf '%s\n' '--- all references to authoritative session in the pinned release ---'
rg -n -C 8 -S 'getAuthoritativeSessionFromCtx|isStateful' "$tmpdir/session.ts"

Repository: superset-sh/superset

Length of output: 5307

🏁 Script executed:

#!/bin/bash
set -e

printf '%s\n' '--- target file ---'
sed -n '1,180p' packages/trpc/src/router/user/user.ts

printf '%s\n' '--- relevant schema definitions ---'
rg -n -C 5 'deletedAt|members|users' packages/trpc packages -g '*.ts' -g '*.tsx' | head -n 300

printf '%s\n' '--- delete/reactivate implementations and call sites ---'
rg -n -C 12 'deleteAccount|reactivateAccount' packages -g '*.ts' -g '*.tsx' | head -n 400

Repository: superset-sh/superset

Length of output: 32542

🏁 Script executed:

#!/bin/bash
set -e
file=packages/trpc/src/router/user/user.ts
printf '%s\n' '--- target file outline ---'
ast-grep outline "$file" --match 'deleteAccount' --view expanded || true
printf '%s\n' '--- target implementation ---'
cat -n "$file" | sed -n '1,180p'
printf '%s\n' '--- database client and schema references ---'
rg -n --glob '*.{ts,tsx}' 'deleteAccount|oauthAccessTokens|oauthRefreshTokens|sessions|transaction\(' packages

Repository: superset-sh/superset

Length of output: 50376

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- database client definitions ---'
fd -i 'client' packages/db packages | head -80
rg -n --glob '*.ts' 'export (const|type).*db|drizzle\(|transaction\s*=' packages/db packages/trpc | head -120
printf '%s\n' '--- auth schema around affected tables ---'
cat -n packages/db/src/schema/auth.ts | sed -n '1,85p;245,310p'
printf '%s\n' '--- representative transactions using this client ---'
cat -n packages/trpc/src/router/v2-host/v2-host.ts | sed -n '110,175p'
cat -n packages/db/src/utils/sql.ts | sed -n '1,65p'
printf '%s\n' '--- package scripts and database package metadata ---'
fd -i 'package.json' . --exec sh -c 'case "$1" in *packages/db/*|*packages/trpc/*) echo "--- $1"; sed -n "/\"scripts\"/,/}/p" "$1" | head -40;; esac' sh {} \;

Repository: superset-sh/superset

Length of output: 13521

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- database clients ---'
cat -n packages/db/src/client.ts | sed -n '1,90p'
printf '%s\n' '--- full affected auth-table relationships ---'
cat -n packages/db/src/schema/auth.ts | sed -n '35,125p;180,310p'
printf '%s\n' '--- all user deletion implementations ---'
cat -n packages/trpc/src/router/admin/admin.ts | sed -n '1,150p'
rg -n -C 8 --glob '*.ts' 'deletedAt|delete\(users\)|deleteAccount' packages/trpc packages/auth packages/db
printf '%s\n' '--- transaction style with db (not dbWs) ---'
rg -n -C 4 --glob '*.ts' 'db\.transaction|dbWs\.transaction' packages | head -180

Repository: superset-sh/superset

Length of output: 50376

🏁 Script executed:

#!/bin/bash
set -e
python3 - <<'PY'
from pathlib import Path
import re

router = Path("packages/trpc/src/router/user/user.ts").read_text()
client = Path("packages/db/src/client.ts").read_text()

body = router.split("deleteAccount:", 1)[1].split("reactivateAccount:", 1)[0]
calls = re.findall(r"await\s+db(?:\s*\n\s*)?(?:\.update|\.delete)", body)
print("deleteAccount uses db calls:", len(calls))
print("deleteAccount contains transaction:", ".transaction(" in body)
print("deleteAccount affected operations:")
for match in re.finditer(r"await\s+db\s*(?:\n\s*)?\.(update|delete)\(([^)]+)", body):
    print(f"  {match.group(1)}({match.group(2).strip()})")

print("db exports neon-http client:", "export const db = drizzle" in client)
print("dbWs exports pooled client:", "export const dbWs = drizzleWs" in client)
PY

Repository: superset-sh/superset

Length of output: 425

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect local subscription status definitions and all Stripe status filters.
rg -n -C 4 --glob '*.{ts,tsx}' \
  'status:\s*"active"|subscriptions\.list|subscriptions\.cancel|subscriptions\.update|status.*trialing' \
  packages apps

Repository: superset-sh/superset

Length of output: 24706

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '--- admin router ---'
sed -n '1,125p' packages/trpc/src/router/admin/admin.ts

printf '%s\n' '--- subscription schema and status usage ---'
rg -n -C 5 --glob '*.{ts,tsx}' \
  'subscriptions\s*=|stripeSubscriptionId|type .*Subscription|status.*trialing|isActiveSubscriptionStatus|inArray\(subscriptions\.status' \
  packages

printf '%s\n' '--- organization deletion and seat-update flows ---'
sed -n '560,610p' packages/auth/src/server.ts
sed -n '680,735p' packages/auth/src/server.ts
sed -n '770,820p' packages/auth/src/server.ts

Repository: superset-sh/superset

Length of output: 40223

🌐 Web query:

Stripe API subscription list status parameter trialing active canceling subscriptions cancel documentation

💡 Result:

In the Stripe API, the status parameter for listing subscriptions allows you to filter returned results based on the subscription's current state [1]. By default, if no status is provided, the API returns only subscriptions that have not been canceled [1]. The following are the behaviors and details for the status parameter when listing subscriptions: Status Parameter Options - Specific Statuses: You can pass any of the valid subscription status strings to filter by that specific state [1]. The available status values are: trialing, active, past_due, canceled, unpaid, incomplete, incomplete_expired, and paused [2][3]. - canceled: Passing status=canceled returns all canceled subscriptions, including those associated with deleted customers [1]. - ended: Passing status=ended returns subscriptions that are canceled, as well as those that have expired due to incomplete payment [1]. - all: Passing status=all returns subscriptions of all statuses [1]. Default Behavior If you do not specify a status parameter in your request, the API defaults to returning all subscriptions that have not been canceled [1]. Note on Status Definitions - trialing: The subscription is currently in a trial period [2][4]. It will transition to active once the trial ends [2]. - active: The subscription is currently in an active state, generally after a successful first payment [2]. - canceled: A terminal status for a subscription [1]. For further implementation details, you can refer to the official Stripe API reference for listing subscriptions [1] and the subscription object definition [4].

Citations:

• 1: https://docs.stripe.com/api/subscriptions/list
• 2: https://docs.stripe.com/api/subscriptions/object?api-version=2025-02-24.acacia
• 3: https://github.com/stripe/stripe-go/blob/85683b51/subscription.go
• 4: https://docs.stripe.com/api/subscriptions/object

🌐 Web query:

site:docs.stripe.com/api/subscriptions/cancel Stripe cancel subscription trialing past_due unpaid incomplete paused

💡 Result:

When you cancel a Stripe subscription, regardless of its current status (such as trialing, past_due, unpaid, incomplete, or paused), the subscription status transitions to canceled [1][2]. Canceling a subscription immediately stops the customer from being charged again for that subscription [1][3]. By default, Stripe also stops the automatic collection of all finalized invoices for that customer upon cancellation to prevent unexpected payment attempts, though you can manually resume collection if needed [1]. The subscription object becomes largely immutable after cancellation, although you can still update its metadata and cancellation_details [1][2]. Depending on your requirements, you can optionally set parameters when canceling: - invoice_now: Set to true to generate a final invoice for un-invoiced metered usage and pending proration items [1][3]. - prorate: Set to true to generate a proration invoice item that credits unused time until the end of the period [2][3]. If you do not cancel immediately, you may alternatively set a subscription to cancel at the end of the current billing period, in which case any pending prorations are collected at that time [1].

Citations:

• 1: https://docs.stripe.com/api/subscriptions/cancel
• 2: https://docs.stripe.com/api/subscriptions/cancel?api-version=2024-06-20
• 3: https://docs.stripe.com/api/subscriptions/cancel?api-version=2025-11-17.preview

🌐 Web query:

site:docs.stripe.com/api/subscriptions/list Stripe list subscriptions auto-pagination default non-canceled limit

💡 Result:

When calling the Stripe API to list subscriptions, the default behavior includes only subscriptions that have not been canceled [1]. You can include canceled subscriptions by explicitly setting the status parameter to canceled [1]. Regarding pagination, the limit parameter defines the number of objects returned per page, with a default value of 10 and a maximum allowed value of 100 [1]. Stripe's official client libraries handle auto-pagination automatically when using iterator methods or equivalent list helpers, iterating through the entire collection as needed based on these API constraints [1].

Citations:

• 1: https://docs.stripe.com/api/subscriptions/list

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '--- shared billing definition ---'
cat -n packages/shared/src/billing.ts

printf '%s\n' '--- membership subscription join ---'
sed -n '28,60p' packages/db/src/utils/membership.ts

printf '%s\n' '--- Stripe subscription creation/status synchronization ---'
rg -n -C 8 --glob '*.{ts,tsx}' \
  'stripeSubscriptionId|subscription\.status|status:\s*(stripe|subscription)|subscriptions\.(create|update|list|cancel)' \
  packages/auth/src packages/trpc/src/router/billing packages/shared/src

Repository: superset-sh/superset

Length of output: 16989

🌐 Web query:

Stripe subscription cancellation API supported statuses trialing past_due unpaid incomplete paused

💡 Result:

The Stripe subscription cancellation API does not impose explicit restrictions on the current status of a subscription in order to initiate a cancellation [1][2][3]. You can cancel subscriptions that are in various statuses, including trialing, active, past_due, unpaid, incomplete, and paused [4][5][6]. When you call the subscription cancellation API, the subscription moves to the canceled status [1][2][7]. Once a subscription is in the canceled status, it becomes largely immutable, meaning you can no longer update the subscription's core configuration, with the limited exception of its metadata and cancellation_details [1][2][3]. For context, the following are the primary statuses a Stripe subscription can hold: incomplete, incomplete_expired, trialing, active, past_due, canceled, unpaid, and paused [4][5][6]. While the cancellation API is generally available, keep in mind that canceling a subscription stops the generation of further invoices [1][3]. Stripe documentation also notes that you may want to check for unpaid invoices before allowing a cancellation if you wish to manage outstanding balances [2][7].

Citations:

• 1: https://docs.stripe.com/api/subscriptions/cancel
• 2: https://docs.stripe.com/api/subscriptions/cancel?api-version=2025-07-30.basil
• 3: https://docs.stripe.com/billing/subscriptions/cancel
• 4: https://docs.stripe.com/api/subscriptions/object
• 5: https://docs.stripe.com/api/subscriptions/object?api-version=2025-02-24.acacia
• 6: https://docs.stripe.com/api/subscriptions/object?api-version=2026-02-25.preview
• 7: https://docs.stripe.com/api/subscriptions/cancel?api-version=2025-11-17.preview

🌐 Web query:

Stripe list subscriptions default non-canceled pagination auto-pagination

💡 Result:

When listing subscriptions in the Stripe API, the default behavior is to return only subscriptions that have not been canceled [1][2]. You do not need to apply specific filters to exclude canceled subscriptions, as this happens automatically unless you explicitly request otherwise (for example, by setting status=canceled or status=all) [1][3]. For retrieving large sets of data, Stripe's official client libraries provide auto-pagination helpers [4][5]. These helpers abstract away the manual process of making multiple API calls, managing cursors (starting_after/ending_before), and checking the has_more property [5][6]. Key points for auto-pagination: 1. Availability: Auto-pagination is supported in all official Stripe SDKs (e.g., Python, Node.js, Ruby, Java, PHP,.NET, Go) [4]. It is not available for raw curl or CLI requests, as those perform single HTTP requests [4]. 2. Usage: You initiate a list call with your required parameters (such as the default non-canceled behavior) and then invoke the library's specific auto-pagination method on the result [4]. Examples include: - Node.js: Use for await on the list response [4]. - Python: Call auto_paging_iter on the returned object [4]. - Java: Call autoPagingIterable on the result [4]. - Ruby: Call auto_paging_each on the returned list [4]. - Go: Auto-pagination is enabled by default in the SDK [4]. By using these helpers, you can iterate through all available subscriptions matching your criteria seamlessly [4][6]. Manual pagination is only required if you are not using an official SDK or prefer to handle the cursor logic yourself [4][6].

Citations:

• 1: https://docs.stripe.com/api/subscriptions/list
• 2: https://docs.stripe.com/api/subscriptions/list?api-version=2026-03-25.dahlia
• 3: https://docs.stripe.com/api/subscriptions/list?api-version=2024-06-20
• 4: https://docs.stripe.com/api/pagination/auto
• 5: https://docs.stripe.com/api/pagination
• 6: https://docs.stripe.com/pagination

• packages/trpc/src/router/admin/admin.ts#L49-L54 (this comment)
• packages/trpc/src/router/admin/admin.ts#L81-L87